What cold-start problem exists for a new item or new user in a vector-similarity recommendation system, and how might you mitigate it?

The cold-start problem has two forms. For a new user, there is no interaction history, so the system cannot build a user embedding from the items they have liked - the recommend API needs positive examples, and there are none. For a new item, there are no users who have interacted with it, so it cannot be used as a positive example and it will not appear in the collaborative-filtering signal. In both cases, the vector-similarity approach that works well for established users and items has no signal to work with. The result is that new users get generic recommendations (usually popularity-based) and new items get no recommendations at all, which means they never accumulate the interactions needed to become established. This is a self-reinforcing problem: items that are never recommended are never engaged with, and items that are never engaged with are never recommended.

The mechanism of the mitigation is to substitute a content-based signal for the missing collaborative signal. For a new user, the system can ask for a few explicit preferences (categories, topics) or use demographic or contextual signals (location, device, referral source) to construct a provisional embedding. For a new item, the system can use the item's content embedding - the same embedding used for search - as its representation, and recommend it to users whose profiles are similar to the item's content. This is content-based recommendation, and it works from day one because the content embedding is available as soon as the item is created. The two approaches can be combined: use collaborative filtering when there is enough history, and fall back to content-based when there is not. The transition happens gradually as the user or item accumulates interactions, with the weight on the collaborative signal increasing over time. The system should also actively explore - show new items to a small fraction of users to gather the interactions needed to bring them into the collaborative signal.

The trade-off is between the quality of the cold-start recommendations and the cost of the fallback. Content-based recommendations are less accurate than collaborative-filtering recommendations for established users, but they are the only option for new users and items. Exploration costs some user satisfaction (showing new items that may not be relevant) but is necessary to gather the data that makes the system better. The common mistake is to ignore cold start and rely entirely on collaborative filtering, which produces a bad first experience for new users and starves new items of engagement. The second mistake is to over-explore, showing too many new items and degrading the experience for established users. The third mistake is to not track the transition out of cold start, so the system does not know when to trust the collaborative signal. The fourth mistake is to use a content embedding that is not aligned with the collaborative space, so the content-based recommendations are poor. Version note: the recommend API and the query API have evolved across releases, but the cold-start pattern (content-based fallback plus exploration) is version-independent. Some versions support using raw vectors as examples in the recommend API, which makes it easier to use a content embedding as a provisional user profile.

Version-dependent: the recommend API and the query API have changed across Qdrant releases. In qdrant-client 1.10+, the query API is unified under query_points, and using raw vectors as examples in the recommend mode may be supported differently. The cold-start pattern itself - content-based fallback plus exploration - is version-independent. If your version does not support using raw vectors as examples, you can still use a content-based query with the user's provisional profile vector directly.